home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
IRIX Installation Tools & Overlays 2002 November
/
SGI IRIX Installation Tools & Overlays 2002 November - Disc 2.iso
/
relnotes
/
eoe
/
ch3.z
/
ch3
Wrap
Text File
|
2002-10-15
|
70KB
|
1,585 lines
- 1 -
3. _C_h_a_n_g_e_s__a_n_d__A_d_d_i_t_i_o_n_s
3.1 _P_l_a_t_f_o_r_m_s__s_u_p_p_o_r_t_e_d
This is an IRIX major release. It supports all current SGI
system types. All system types supported in IRIX 6.2, 6.3,
and 6.4 are supported in this release, with the exception of
Crimson systems. IRIX 6.2 was the last release to support
Crimson.
This release of IRIX will support the R12K as it becomes
available in systems. The R12000 performance counter
implementation is different than the R10000, and this
required changes in the ABI providing access to the
counters. This change is visible to users using utilities
such as perfex. Please check the man pages for exact
differences. (perfex(1), r10k_counters(5))
Use of the performance counters on systems with a mixture of
R10000 and R12000 cpus installed is currently not supported,
and may cause incorrect results to be reported.
A system tuneable "perfcnt_arch_swtch_sig" can be set with
systune(1m) to the signal number that will be send to the
process group in case a process using performance counters
is scheduled on CPUs with different event meanings. The
default for this value is "0". Please note that such
differences exist between R10000 Rev 2.X and R10000 Rev 3.0
as well and a signal would be sent for these cases as well.
The tunable "perfcnt_arch_swtch_msg", if set to a non-zero
value, will cause a message to be logged via syslogd when a
signal is sent.
3.2 _G_e_n_e_r_a_l__O_S__F_e_a_t_u_r_e__C_h_a_n_g_e_s
IRIX 6.2 was an all-platform release which supported all
hardware platforms not considered obsolete at its time of
release (March 1996). The following features are new or
significantly changed since IRIX 6.2 (some were first
released in IRIX 6.3 or 6.4).
+o The version of sendmail previously installed with IRIX
(8.8.8) has been replaced with Sendmail.org's sendmail
version 8.9.3. There are many differences between IRIX
sendmail version 8.8.8 and version 8.9.3. Some of the
new functions in version 8.9.3 are as follows:
- 2 -
+o The major difference between sendmail versions
8.8.8 and 8.9.3 is their configuration file. The
configuration file in sendmail version 8.9.3 is
configured with the sendmail.mc file which is
processed with the m4 macro processor to create
the sendmail.cf file.
+o A new version of configmail configures the
sendmail.mc file and provides features similar to
the configmail utility in previous versions of
IRIX. This version of configmail also processes
the sendmail.mc file into sendmail.cf by using the
m4 macro processor.
+o Sendmail 8.9.3 includes many new features
requested by IRIX users, such as anti-relay
features which can be used to control spam
messages.
For more information on the 8.9.3 version of sendmail,
see the _I_R_I_X _A_d_m_i_n_i_s_t_r_a_t_i_o_n: _N_e_t_w_o_r_k_i_n_g _a_n_d _M_a_i_l guide.
For more information on how to configure sendmail
8.9.3, see http://www.sendmail.org/m4/readme.html.
+o The Irix name services have been completely rewritten.
The new implementation known as the Unified Name
Service is fully documented in the _I_R_I_X _A_d_m_i_n:
_N_e_t_w_o_r_k_i_n_g _a_n_d _M_a_i_l guide. The following are the most
obvious changes:
+o All name service lookups are now cached in
databases located in the directory /_v_a_r/_n_s/_c_a_c_h_e.
+o A new daemon _n_s_d has been added to maintain the
name service cache and manage all network name
service requests for the system.
+o A configuration file /_e_t_c/_n_s_s_w_i_t_c_h._c_o_n_f now
controls the resolve order for all name services.
The _h_o_s_t_r_e_s_o_r_d_e_r keyword in /_e_t_c/_r_e_s_o_l_v._c_o_n_f is
now ignored.
+o The _y_p_b_i_n_d and _y_p_s_e_r_v daemons have been replaced
by the _n_s_d daemon. The services which were
provided by the _y_p_b_i_n_d daemon are now included in
the protocol library /_v_a_r/_n_s/_l_i_b/_l_i_b_n_s__n_i_s._s_o.
The services which were provided by the _y_p_s_e_r_v
daemon are now included in the protocol library
/_v_a_r/_n_s/_l_i_b/_l_i_b_n_s__n_i_s_s_e_r_v._s_o.
+o The BIND resolver routines in the C library are no
longer used in name service lookups. Lookups to
- 3 -
DNS are now done by the _n_s_d daemon using routines
in the protocol library /_v_a_r/_n_s/_l_i_b/_l_i_b_n_s__d_n_s._s_o.
+o Certain commands which used to explicitely use NIS
calls now call through the name service and may
behave differently. An example is finger which
used to list non-local users which were not listed
in the password file, but now does not.
+o The Hardware Graph provides a foundation for managing
devices on systems with large, topologically complex
I/O subsystems. You will notice that several
directories in /_d_e_v are now symlinks to /_h_w. You
should not attempt to unmount /_h_w. Please refer to the
_h_w_g_r_a_p_h(4) manual entry for more information.
+o The device nodes created by XLV are in /_d_e_v/_x_l_v and
/_d_e_v/_r_x_l_v.
+o Support for the lv(7M) logical volume manager has been
removed. It is replaced by the xlv(7M) logical volume
manager. The utility lv_to_xlv(1M) can be used to
easily convert lv volumes to equivalent xlv volumes.
In addition to the disk striping and concatenation
features provided by lv, xlv supports disk mirroring
and on line volume administration features that are not
available with lv.
+o The permissions of various devices can now be
controlled via the _i_o_c_o_n_f_i_g(1M) program. See
_i_o_c_o_n_f_i_g(1M) for more information on setting device
file permissions.
+o The compiler shipped with this release is the MipsPRO
7.2.1 compiler product.
+o IRIX 6.4 was the first operating system release to
support the new Scalable Shared Memory Processing
(S2MP) architecture from SGI. The Origin200,
Origin2000 and Onyx2 are the first machines to
implement this new MP architecture, which provides
extremely cost effective scaling of memory and
processor bandwidth across a wide range of system
configurations. The key architectural difference
between S2MP systems and previous Symmetric
Multiprocessor (SMP) systems, like the Challenge and
PowerChallenge, is that the single shared SMP bus has
been replaced by an expandable hypercube interconnect
which provides a high bandwidth, low latency, cache
coherent global view of system memory. A directory
based coherency scheme provides a consistent view of
- 4 -
memory to all processors, but the latency for a
particular processor to fetch a particular word from
memory depends on the relative position of the
processor and memory in the topology of the system.
One of the key considerations for the operating system
on an S2MP machine is to insure that processes and the
data that they access are mapped efficiently onto the
resources of the system. Significant work has been
done on the design of the IRIX Virtual Memory and
Scheduler subsystems to allow IRIX to manage resource
locality on S2MP systems. Most of these changes will
not be visible to users, system administrators or
application programmers. In most cases, the default
policies provided by the operating system will allow
existing IRIX binaries, both single-threaded and
parallel programs, to run extremely efficiently on S2MP
systems. For the rare cases in which the default
policies provided by IRIX do not match the needs of the
application, several levels of tools are provided to
allow applications to be mapped onto the hardware in an
optimal way:
- Compiler directives for sophisticated control of
the mapping of application processing and data
onto the machine architecture. Refer to Chapter 6
of the _M_I_P_S_p_r_o _F_o_r_t_r_a_n _7_7 _P_r_o_g_r_a_m_m_e_r'_s _G_u_i_d_e
(document number 007-2361-004) for more
information on the new features to support S2MP
systems.
- A memory and process placement tool, _d_p_l_a_c_e(1),
which allows the programmer or user to specify the
mapping of an application onto the system in a
simple high level script language without
modifying the binary executable. Please refer to
the _d_p_l_a_c_e(1) manual entry for more information.
- A memory access analysis tool, _d_p_r_o_f(1), which can
be used to understand the memory reference
patterns of an application. _d_p_r_o_f can also be
used automatically to generate _d_p_l_a_c_e input script
files. Please refer to the _d_p_r_o_f(1) manual entry
for more information.
+o IRIX 6.5 on S2MP systems provides a sophisticated
dynamic memory migration facility to allow parallel
codes with memory sharing patterns that change during
execution to achieve excellent performance without code
modifications. The S2MP hardware includes a mechanism
for detecting pages which are being accessed remotely,
rather than locally. An interrupt is generated to the
- 5 -
kernel, which then migrates the physical page to the
appropriate location in the system to maximize locality
of references. The migration control system in the
kernel contains sophisticated mechanisms to prevent
bouncing of pages and to balance the load on the
system. On systems up to 32 processors, all memory in
the system is sufficiently close topologically that
page migration is normally not required. By default,
the migration mechanism is not enabled until requested
by an application. One way to do this is by using the
-_m_i_g_r_a_t_i_o_n command of _d_p_l_a_c_e(1). The default behavior
of the migration system can also be controlled by
setting the following system tunable parameters:
_n_u_m_a__m_i_g_r__b_a_s_e__e_n_a_b_l_e_d and _n_u_m_a__m_i_g_r__b_a_s_e__t_h_r_e_s_h_o_l_d.
Refer to the comments in the tunable file
/_v_a_r/_s_y_s_g_e_n/_m_t_u_n_e/_n_u_m_a for information about the
possible values and their effects.
+o The new command _s_n(1) command provides an interface for
controlling the migration system. Please see the
manual entry for details.
+o The new command _n_s_t_a_t_s(1) prints statistics about the
behavior of the memory management system. Refer to the
_n_s_t_a_t_s(1) manual entry for details.
+o IRIX 6.5 on S2MP systems provides dynamic memory
replication facility for creating replicas of read-only
shared pages, for example code pages of commonly used
shared libraries (DSOs) like _l_i_b_c. On S2MP systems up
to 32 processors, this facility is not enabled by
default, but it can be activated by modifying the
system tunable parameter _n_u_m_a__p_a_g_e__r_e_p_l_i_c_a_t_i_o_n__e_n_a_b_l_e
which is defined in the file /_v_a_r/_s_y_s_g_e_n/_m_t_u_n_e/_n_u_m_a and
can be modified by using the _s_y_s_t_u_n_e(1M) utility.
+o The IRIX 6.5 virtual memory system has been enhanced to
allow processes to select different page sizes for
different portions of their virtual address space. The
default page size remains 16KB, as in IRIX 6.2, for
systems that support 64bit addresses, and 4KB for
systems such as O2 that support only 32 bit addresses.
On the Origin200, Origin2000 and Onyx2 systems, using
the R10000 processor, the following page sizes may be
selected: 16KB, 64KB, 256KB, 1Mb, 4Mb and 16Mb. A
process can mix page sizes within a range of addresses,
as appropriate. By default, the system will attempt to
keep 20% of free system memory available as 64KB pages,
but this behavior can be modified by setting the system
tunables in the _l_p_a_g_e__w_a_t_e_r_m_a_r_k_s group. By using
larger pages, programs with large datasets may achieve
- 6 -
a significant performance boost by minimizing TLB miss
overhead. The _p_e_r_f_e_x(1) program can be used to monitor
the number of TLB misses incurred by an application,
which will give an indication of whether large pages
will useful to a particular code. There are several
ways to request page sizes other than the default.
Please refer to the _d_p_l_a_c_e(1) manual entry for one
example.
+o XFS with this release of IRIX supports two new
features: XFS quotas and automatically aligned inode
allocation. The implementation of these features
resulted in changes to the XFS on-disk filesystem data
structures. As a result, XFS filesystems made with
this release of IRIX will not be mountable by systems
running any earlier IRIX release (5.3XFS, 6.2, 6.3, or
6.4) unless the current XFS patch for the older
releases are first installed (a new miniroot from the
patch will also be necessary if a root disk is to be
used). This should normally be installed as part of a
patchset, not by itself.
+o IRIX 6.5 will be the last major release of IRIX that
will support read/write EFS filesystems. In future
releases of IRIX, EFS filesystems will be mountable
only in read-only mode. EFS will continued to be
supported for CD-ROM devices, and to allow old disks to
be backed up or read. We strongly encourage that all
new filesystems be made as XFS filesystems; the mkfs
program and the miniroot now default to creating XFS
filesystems.
+o The scheduler in IRIX 6.5 has been improved in a number
of areas. The previous notions of degrading and non-
degrading priority processes have been replaced by more
powerful and flexible realtime and timesharing
scheduling disciplines. The timesharing discipline
implements a currency-style scheduler, rather than the
classic UNIX priority degradation mechanism for
guaranteeing fairness. The meanings of the process
priority values have been changed significantly.
Several new system calls were added to request and
modify the parameters of the new scheduling
disciplines. Please refer to the _r_e_a_l_t_i_m_e(5),
_s_c_h_e_d_c_t_l(2), _s_c_h_e_d__s_e_t_s_c_h_e_d_u_l_e_r(2) and _n_p_r_i(1) manual
entries for further details.
+o The _p_s_e_t(1M) and deadline scheduling facilities of IRIX
6.2 have been obsoleted and are not present in this
release.
- 7 -
+o This release of IRIX contains a system threading
facility, and many system daemons (such as _v_h_a_n_d and
_b_d_f_l_u_s_h) now run as system threads. These daemons, like
all system threads, are not now visible through _p_s(1),
though they will be in a future release through a ps-
like mechanism. System threads are used for device
interrupts, parts of network service code, and user
process system call handling. System I/O thread
management services will be provided in future releases
as part of the Hardware Graph facility.
+o The values which are assigned for Process Identifiers
(PIDs) have changed significantly from previous
releases. This may cause problems for some non-
portable applications. Prior to IRIX 6.5, PIDs would
generally be assigned in increasing value -- often
interpretable as consecutive integers -- which would
wrap around in value somewhere around 30 thousand.
Under IRIX 6.5 and later, PIDs are assigned values that
are not predictable and the maximum PID value is now
considerably larger, at approximately 2 billion. All
portable applications should treat PID values as opaque
objects with a potentially large and sparse value
space. This change was made to support larger numbers
of simultaneous processes while increasing performance.
+o The _r_t_n_e_t_d(1M) command is no longer supported on any
platform, and the contents of /_e_t_c/_c_o_n_f_i_g/_r_t_n_e_t_d and
/_e_t_c/_c_o_n_f_i_g/_r_t_n_e_t_d._o_p_t_i_o_n_s are ignored. Networking
threads such as _n_e_t_p_r_o_c and _s_o_c_k_d may have their
priorities adjusted by using _s_y_s_t_u_n_e(1M) to control
parameters in the ``sthread'' group. See
/_v_a_r/_s_y_s_g_e_n/_m_t_u_n_e/_k_e_r_n_e_l for an explanation of these
parameters.
+o A new tunable, min_bufmem, has been introduced in IRIX
6.5.1m. It is the minimum amount of memory held by
filesystem meta-data that will be cached in the buffer
cache when the system runs into low memory conditions.
The default value for min_bufmem is set to 2% of
physical memory.
+o The new 6.5 Desktop has been oriented towards using the
Web as a medium to transfer visual/written information.
+o A majority of the binaries installed from the 6.5
images have been compiled N32/mips3 instead of
O32/mips2.
+o The size of _c_p_u_i_d__t has increased from 8 to 16 bits so
some /_p_r_o_c interfaces are not backward binary
- 8 -
compatible
+o The default compilation mode with this release has been
changed from previous releases, to now be optimized for
the machine the compilation is run on. In particular
for Origin, Onyx2 and OCTANE systems the default is
n32/mips4/R10K. This is controlled by the
/etc/compiler.defaults file. Please refer to _c_c(1) for
more details on compilation modes.
+o The version of Perl that comes with IRIX has been
updated to 5.004_05. Previous releases of IRIX shipped
with either v4.036 (IRIX 5.1 through 6.3), v5.003 (IRIX
6.4), or v5.004_04 (IRIX 6.5 through 6.5.16). The
standard Perl library has been moved to
/usr/share/lib/perl5, and is in a separate subsystem
(eoe.sw.gifts_perl_lib) that is installed by default.
Perl5 was a complete rewrite of the language, with many
new features. Due to minor incompatibilities, Perl5 is
not a strict superset of Perl4. Porting scripts from
Perl4 to Perl5 is normally very straight-forward.
Instructions are in the "perltrap" man page.
For backward compatibility, Perl5 supports the Perl4
method of accessing system structures, using the '*.ph'
translated C header files (see the "h2ph" man page).
The translation process is error-prone, and is no
longer supported by the Perl community. It is highly
recommended to translate your Perl scripts to use Perl5
modules. See the "perlmod" manpage.
Perl5 was previously available on the Freeware CD.
There are several differences between the IRIX EOE
Perl5 and the Freeware perl5:
This is v5.004_05, old Freeware versions were
5.001m and 5.002 (v5.003 and 5.004_04 were
available unofficially). Recent and Current
Freeware versions are 5.005_03 and 5.6.1.
The path to install extensions for the IRIX EOE
Perl is /usr/share/lib/perl5/site_perl. Any
extensions that you were using with the Freeware
Perl will need to be re-installed. The Freeware
perl is not removed by this installation, so you
can change the interpreter line in your scripts.
This minor upgrade from v5.004_04 to v5.004_05
maintains complete binary compatibility. It mostly
contains bug fixes, and upgrades to many of the
included standard modules. The IRIX EOE Perl5 is
compiled -n32 -mips3 with 64bit ints, and will not
- 9 -
load pre-5.003 or Freeware extensions (compiled
-32), so you must recompile and reinstall any
extensions that you use. Non-compiled (perl-only)
extensions should work, if they are in the @INC
load path.
The old perl binary and many of the extensions
remain installed, so perl scripts that rely on
bugs that are fixed may well continue to work by
changing the interpreter line to explicitly use
the old version: #!/usr/sbin/perl5.00404
Any customized Perl4 library files placed in the Perl4
library location /usr/lib/perl will need to be copied
(and checked for problems under Perl5) to
/usr/share/lib/perl5/site_perl. Perl5 is designed to
allow different versions and different architectures to
coexist. The Freeware (-32) and EOE (-n32) Perls are
configured to be different architectures ("irix" and
"irix-n32" respectively). Therefore, if
/usr/freeware/lib/perl5/site_perl and
/usr/share/lib/perl5/site_perl are symlinked to the
same directory, then they can safely and usefully share
extension modules.
+o IRIX 6.5.3 now contains support for the ISO8859-15
encoding which includes the new Euro currency symbol.
The new encoding differs from ISO8859-1 by 8
characters:
0xA4 Euro sign
0xA6, 0xA8 Latin capital and small s with caron
0xB4, 0xB5 Latin capital and small z with caron
0xBC, 0xBD Latin capital and small ligature oe
0xBE Latin capital y with diaeresis
It is known to _i_c_o_n_v(1) which can be used to convert
data to and from other supported encodings such as
Unicode.
For every locale previously available in IRIX and whose
written language could be represented in ISO8859-15, a
new locale was added, for a total of 25 new locales.
Out of those, 9 locales (de_AT, de_DE, es_ES, fi_FI,
fr_BE, fr_FR, it_IT, nl_NL, pt_PT) have had their
currency format updated to reflect the participation of
their country in the European Monetary Union. The new
locales can be selected by a user through the language
customization panel, accessible from the toolchest. The
locales themselves can be modified with the
- 10 -
_l_o_c_a_l_e_d_e_f(1) utility by a call such as:
#### ppppwwwwdddd
////uuuussssrrrr////lllliiiibbbb////llllooooccccaaaalllleeee////ffffrrrr____FFFFRRRR....IIIISSSSOOOO8888888855559999----11115555
#### llllooooccccaaaalllleeeeddddeeeeffff ----ffff ........////cccchhhhaaaarrrrmmmmaaaapppp////IIIISSSSOOOO8888888855559999----11115555 ----iiii ffffrrrr____FFFFRRRR....IIIISSSSOOOO8888888855559999----11115555....ssssrrrrcccc ....
This release of IRIX contains two new fonts
(_7_x_1_3_e_u_r_o._p_c_f._Z and _7_x_1_3_e_u_r_o_B._p_c_f._Z) which can be used
in conjunction with the new locales. They contain the
Euro Symbol and they have the encoding FCD8859-15. They
are part of the basic operating system and are
installed by default. In addition, the Euro Symbol and
encoding ISO8859-15 were added to the twelve European
typefaces (4 Dutch 801, 4 Swiss 721, and 4 Courier 10-
Pitch). They now each have 1016 characters. They are
contained in the subsystem _x__e_o_e._s_w._X_u_n_i_c_o_d_e_f_o_n_t_s.
To input the Euro sign, one can either assign it to a
specific key using _x_m_o_d_m_a_p(1) or it can be generated
using one of the three new compose sequences (see
_c_o_m_p_o_s_e_t_a_b_l_e(5)):
<<<<AAAAllllttttGGGGrrrr>>>> <<<<cccc>>>> <<<<====>>>>
<<<<AAAAllllttttGGGGrrrr>>>> <<<<eeee>>>> <<<<====>>>>
<<<<AAAAllllttttGGGGrrrr>>>> <<<<eeee>>>> <<<<---->>>>
+o IRIX 6.5 has a newer version of _t_o_p(1) supporting
interactive manipulation of running processes and more
extensive machine state and multiprocessing support.
+o IRIX 6.5 now includes Berkeley DB 1.85 library.
+o IRIX 6.5 _i_n_s_t_a_l_l(1) was enhanced to be GNU/BSD
compatible. It can now be invoked from typical GNU
makefiles using the GNU/BSD syntax and do what's
expected.
+o A new product called gnu.*.* was added to the IRIX 6.5
base CD. It includes a big subset of the GNU commands.
This product installs under /usr/gnu and needs to be
explicitly selected for installation (i.e. it does not
install by default.)
+o IRIX 6.5 _c_r_o_n_t_a_b(1) was enhanced to allow root to
edit/list/remove other users' crontabs. _c_r_o_n(1) was
enhanced to provide more information on cron/at jobs
that produced output like the vixie cron used on Linux
and FreeBSD.
+o In IRIX 6.5, the content of the _L_C__C_T_Y_P_E locale
category has been extended to comply with the XPG/4
- 11 -
standard. The _L_C__C_T_Y_P_E binary format has changed and
the old format will not be recognized by the C library.
Therefore, all custom-built locales generated under
IRIX 6.4 or earlier releases must be re-generated with
the IRIX 6.5 version of _l_o_c_a_l_e_d_e_f(1) and associated
_c_h_r_t_b_l(1M) or _w_c_h_r_t_b_l(1M) commands when the system is
upgraded to IRIX 6.5.
The change was required because the old data structure
created by _c_h_r_t_b_l(1M) allowed a maximum of eight (8)
character classes to be defined. This was not
sufficient to fully support the 11 basic character
classes required by XPG/4. The new data structures
were implemented by extending the _c_t_y_p_e(3C) table to
contain 32-bit per character of character
classification information. The three basic _c_t_y_p_e(3C)
macros (_i_s_a_l_p_h_a, _i_s_g_r_a_p_h, and _i_s_p_r_i_n_t) were redefined
to comply with XPG/4. These changes were implemented
in the C library while preserving backward
compatibility. Therefore, the executables compiled
under IRIX 6.4 or earlier will continue to work
identically under IRIX 6.5. However, new binaries
compiled under IRIX 6.5 that use the _c_t_y_p_e(3C) or the
_c_o_n_v(3C) macros will not run under a previous release
of IRIX.
+o IRIX 6.5 now supports the POSIX 1003.1e least-privilege
mechanism, _c_a_p_a_b_i_l_i_t_i_e_s. Please refer to
_c_a_p_a_b_i_l_i_t_i_e_s(4) for more details.
+o IRIX 6.5 now supports POSIX 1003.1e Access Control
Lists (_A_C_Ls) on files and directories. Please refer to
_a_c_l(4) for more details.
+o Both IRIX 6.4 and IRIX 6.5 have introduced changes to
the data stream produced by the System Audit Trail
facility. Although these changes will not affect users
of the IRIX SAT tools (sat_interpret, sat_reduce,
etc.), it will affect users of extended accounting (see
_e_x_t_a_c_c_t(5)) or of any software that makes use of the
extended accounting data. A new tool, _a_c_c_t_c_v_t(1), has
been provided to convert the accounting records from
the System Audit Trail facility back into the formats
written by either IRIX 6.2 or IRIX 6.4. In most cases,
this should allow existing extended accounting software
to run under IRIX 6.5 without modification. For more
details, see the _a_c_c_t_c_v_t(1) reference pages.
+o IRIX 6.3, 6.4, and 6.5 have improved serial port
support. On newer machines, bit (a.k.a. baud) rates
greater than 38400 bps are now supported. O2, OCTANE,
- 12 -
Onyx2, Origin2000, and Origin200 all support bit rates
up to at least 115200 bps. Audio/Serial Option, on
Onyx/Challenge systems, also supports high bit rates.
Older machines, including Indigo, Indy, Indigo2, and
Onyx/Challenge built-in ports, still support only up to
38400 bps due to hardware limitations.
Many tools built in to IRIX now support higher bit
rates. Examples include _c_u(1), _i_n_i_t(1), _g_e_t_t_y(1),
_l_o_g_i_n(1), _p_p_p(1), _s_l_i_p(1), and _s_t_t_y(1).
See the _s_e_r_i_a_l(7) and _t_e_r_m_i_o(7) man pages for more
information on serial ports hardware and programming.
+o A new kernel debugging facility has been introduced
with IRIX 6.5.1. This facility is installed with
eoe.sw.kdebug but is not enabled by default. Refer to
the comments about debug tunables in
/_v_a_r/_s_y_s_g_e_n/_m_t_u_n_e/_k_e_r_n_e_l for information about using
the facility.
+o Irix 6.5.2f contains a set of IRIX commands, libraries
and desktop applications which have been
internationalized to support Japanese Shift-JIS,
Traditional Chinese Big5 and Simplified Chinese GBK
encoding. The following have been internationalized:
+o POSIX.2 Shell and built-in commands
ksh sh
[ alias bg cd command
fc fg getopts hash jobs
kill read type ulimit umask
unalias wait
+o IRIX commands
awk(nawk) basename bc bfs
cat chmod chown chgrp
cmp col comm compress
csplit ctags cut date
diff diff3 dircmp dirname
env expand expr file
getopt grep head id
logname ls man manwhat
mkdir mkfifo more mt
nice nl nohup od
pathchk pg pr printf
renice rm rmdir rmt
- 13 -
sort spell split strings
sum tabs tail tar
time top touch tr
uname uncompress unexpand uniq
wc who xargs zcat
lp accept cancel disable
lpenabled lpsched lpshut lpstat
captoinfo infocmp tic tput
+o Libraries
libc libX11 libgen libw
+o Desktop Applications
iwsh ieditor ipanel
+o Shift-JIS Roman Numeral Enhancements for Roman numerals
consist of the lower and upper case numbers one through
ten and other non-kanji characters in the range of
0xFA40 through 0xFA5C in the Shift-JIS IBM Extended
Character Set. Shift-JIS characters in this range can
be input (using code numbers) and displayed. Other
code points in the user defined (gaiji) code area
(0xF040 through 0xF9FC) can also be handled internally
but fonts are not provided.
+o The internationalization of IRIX commands affected the
behavior of some commands in a multibyte locale. The
differences in functionality between a single byte and
multibyte locales are summarized below.
+o oooodddd
----tttt aaaa and ----cccc option
For all multibyte (mb) characters, a character
will be displayed at the first byte location and
the character sequence "**" will be displayed for
the rest of the bytes of the mb character. If
the mb character is not printable (i.e., not
iiiisssswwwwpppprrrriiiinnnntttt((((3333cccc))))), a three-digit octal value
corresponding to each byte of the mb character is
displayed.
----jjjj option
If the dump is a character dump (----cccc option) and
the number of bytes to be skipped does not end at
a character boundary for multibyte characters,
then the character sequence "**" will be displayed
- 14 -
for the bytes which are a part of the incomplete
mb character broken by the skip operation.
----NNNN option
If the dump is a character dump (----cccc option) and
the number of bytes to be displayed ends at the
start of a multibyte character, then the complete
character will be displayed at the first position.
Otherwise, if the number of bytes to be displayed
does not end at a character boundary, then the
character sequence "**" will be displayed for the
bytes which belong to the incomplete mb character.
+o ppppaaaasssstttteeee
When the length of the output line exceeds 4095
bytes, an error message will be printed for each
extra bytes ignored in the output.
When the ----ssss option is not given and if all the
files with maximum number of lines do not have an
EOL in their last line, the output corresponding
to that line number is not printed.
+o sssspppplllliiiitttt
The -b option specifies the output file size in
bytes. When a multibyte character is involved in
the split, a mb character may be split into two
different files due to the bytes count.
+o ttttrrrr
In a single byte locale, calling tr without
arguments will produce an error message requesting
for more arguments. In a multibyte locale, tr will
wait for input on stdin and output lines
unaltered.
ttttrrrr ''''[[[[----]]]]'''' ''''xxxx''''
In a single byte locale, this command will
replaces all non-lowercase characters by 'x'. In a
multibyte locale, it will replaces '-' by 'x'.
+o uuuunnnneeeexxxxppppaaaannnndddd
If more than 100 tab stops are specified, the
extra tab stops are silently ignored. If an
illegal multibyte character sequence is
- 15 -
encountered in input, uuuunnnneeeexxxxppppaaaannnndddd will exit
immediately with an error message.
+o uuuunnnniiiiqqqq ----ssss
This option skips characters (per X/Open) and not
columns (per man pages).
+o A set of new _f_c_n_t_l(2) commands is added to implement
_o_p_p_o_r_t_u_n_i_s_t_i_c _l_o_c_k_s (_o_p_l_o_c_k_s) over XFS filesystems. An
oplock is a _S_e_r_v_e_r _M_e_s_s_a_g_e _B_l_o_c_k (_S_M_B) construct used
to grant exclusive access of a file to an SMB client.
When another user accesses the same file, the SMB
server revokes the oplock to the first user while the
second user waits. This kernel level oplock allows the
owning SMB server to receive file access notification
from users over NFS, XFS, or SMB. See the _f_c_n_t_l(2)
manual page for more details.
This new feature is available only in the _f_e_a_t_u_r_e
_o_v_e_r_l_a_y. These fcntl commands will fail EINVAL when
run on a kernel without the feature overlay or when the
_o_p_l_o_c_k_s__e_n_a_b_l_e_d systune variable is set to 0.
+o _r_u_n_o_n(1) can run a command on a cpu that is part of a
cpuset only if the user has proper permission to access
the cpuset.
+o For systems with the NFS server enabled, the number of
nfsd NFS server daemons to create by default at startup
has been changed. Previously the default was four. Now
the default is to create as many nfsds as the system
has CPUs which are available to schedule unrestricted
processes, but no less than four. This should improve
NFS server performance on larger machines. The new
default can be overriden by specifying an alternative
in the file /etc/config/nfsd.options.
+o In IRIX 6.5.8, _f_a_m(1M) was modified to place temporary
files (including sockets used to connect to _f_a_m(1M) in
$TMPDIR if set, however some problems were encountered.
From IRIX 6.5.16, _f_a_m(1M) will revert to the previous
behavior, and place all temporary files in /tmp.
Please ensure that /tmp exists, and that users of _F_A_M
have read and write access to that directory.
+o The IRIX 6.5.18 release introduces read-only support
for the UDF filesystems format typically used for DVDs
and packet-written CD-RWs. UDF support is installed
with subsystem _e_o_e._s_w._u_d_f. IRIX support for UDF
- 16 -
filesystems does not, however, include support for
playing DVD movies. DVDs will be automatically mounted
by mediad in the same way that CD-ROMs are
automatically mounted. (DVDs will be mounted under
/CDROM.)
Not all features of UDF, however, have been implemented
in IRIX. For example, IRIX does not support the
following UDF features: multiple partitions, symbolic
links, extended attributes, strategy 4096 ICB
hierarchies, and virtual allocation tables.
3.3 _C_h_a_n_g_e_s__t_o__t_h_e__I_n_s_t_a_l_l_a_t_i_o_n__T_o_o_l_s
IRIX 6.5 features enhancements to the IRIX software
installation utilities, _i_n_s_t and _S_o_f_t_w_a_r_e _M_a_n_a_g_e_r (_s_w_m_g_r).
These changes are summarized below. See the _i_n_s_t(_1_M) manual
page, and the _S_o_f_t_w_a_r_e _I_n_s_t_a_l_l_a_t_i_o_n _A_d_m_i_n_i_s_t_r_a_t_o_r'_s _G_u_i_d_e
for more details.
+o Inst and swmgr now support a new type of installation
product called an _o_v_e_r_l_a_y. Overlays, like patches, are
products that only contain the subset of files from the
base release that have been changed to fix a specific
problem or set of problems. Unlike patches, however,
the files that are being replaced are not saved.
Therefore, it is not possible to remove an overlay
without reinstalling the original base product. The
name of the overlay product is the same as the name of
the product it will upgrade. Thus, an overlay for the
eoe product will also have the product name eoe. Two
distinct types of overlays are supported : maintenance
overlays and feature overlays. Maintenance overlays
contain bug fixes and minimal support for new hardware.
Feature overlays contain bug fixes, support for new
hardware, and new software and hardware features.
These two overlay types may not be mixed. Thus, a
system may have feature overlays installed or maint
overlays installed but not both. Any attempt to install
both overlay types will result in an installation
conflict. Showfiles has a new option, -_w, that shows
only files that were installed as part of an overlay
subsystem. Showprods also has a new option, -_o, to
show only overlay subsystems.
+o For 6.5.5, the default value of the
_s_m_a_r_t__c_o_n_f_i_g__h_a_n_d_l_i_n_g preference was changed to _o_n.
This change should reduce the amount of config file
merging required after 6.5.x installations.
- 17 -
+o For 6.5.4, the conflicts mechanism has been improved.
When prerequisite conflicts are displayed, the name of
the CD where the missing product resides is listed in
the conflict message if that information is available.
In addition, redundant products are no longer displayed
in the conflict messages.
+o For 6.5.3, the selection keyword _s_t_a_n_d_a_r_d has been
modified to automatically include those subsystems
selected by the _p_r_e_r_e_q_s keyword, and to exclude those
subsystems selected by _i_n_c_o_m_p_l_e_t_e_o_v_e_r_l_a_y_s keyword. As
a result, the command sequence _k_e_e_p * followed by
_i_n_s_t_a_l_l _s_t_a_n_d_a_r_d is recommended for performing an
upgrade. In Software Manager, the recommended upgrade
procedure can be invoked from the Install menu (see
below.)
+o For 6.5.3, the single inst command _i_n_s_t_a_l_l _m_a_i_n_t can be
used to switch from the feature stream to the
maintenance stream, and make the appropriate product
selections. Similarly, the _i_n_s_t_a_l_l _f_e_a_t_u_r_e command can
be used to switch from the maintenance stream to the
feature stream. These commands should be issued after
all the necessary CDs have been opened. Note that when
switching streams, it may be necessary to insert the
base IRIX 6.5 CDs in addition to the IRIX 6.5.3 overlay
CDs.
+o For 6.5.3, Software Manager has a new _I_n_s_t_a_l_l menu for
convenience. This menu can be used only after opening
the desired CD or CDs, and choosing Customize
Installation mode. The Install menu has the following
three items: Select Recommended Upgrades - this makes
the appropriate selections for an upgrade, using the
inst commands _k_e_e_p * and _i_n_s_t_a_l_l _s_t_a_n_d_a_r_d, described
above; Switch to Maintenance Stream - performs the inst
command _i_n_s_t_a_l_l _m_a_i_n_t, described above; Switch to
Feature Stream - performs the inst command _i_n_s_t_a_l_l
_f_e_a_t_u_r_e, described above.
+o For 6.5.2, some of the inst messages displayed when
reading distributions were changed slightly to be more
descriptive.
+o For 6.5.1 and later, two new overlay related inst
keywords, _o_v_e_r_l_a_y_s and _i_n_c_o_m_p_l_e_t_e_o_v_e_r_l_a_y_s, have been
added. _o_v_e_r_l_a_y_s lists the overlay subsystems present
in the distribution. _i_n_c_o_m_p_l_e_t_e_o_v_e_r_l_a_y_s lists the
overlay subsystems that are not installable because of
missing prerequisites. _k_e_e_p _i_n_c_o_m_p_l_e_t_e_o_v_e_r_l_a_y_s will
deselect all the uninstallable overlays.
- 18 -
+o Applicable patch products are now selected for default
installation. The selected patches will apply to
either installed base products or distribution base
products that are marked for install. Patches that
were automatically selected for install will also be
automatically deselected if the accompanying base
product is either deselected or marked for remove. See
the _a_u_t_o_p_a_t_c_h_s_e_l_e_c_t preference for more information.
+o The new inst command _o_p_e_n can be used to view or
install software from multiple distributions. The main
benefit of this is conflict resolution across
distributions. The related command, _c_l_o_s_e, is used to
close a distribution that has previously been opened.
_s_w_m_g_r provides identical capabilities from the File
menu.
+o When multiple distributions are open, the available
inst keywords may be constrained to a particular
distribution by prefacing each keyword with a substring
that uniquely identifies the distribution of interest
followed by a colon. For example, _l_i_s_t _A_p_p_l_i_c_a_t_i_o_n: _N,
would list only the new products on the Irix
Application CD.
+o When attempting to install a product from multi-user
mode that requires a miniroot installation, _i_n_s_t or
_s_w_m_g_r will boot the miniroot and continue the install
automatically in the miniroot. See the _l_i_v_e__i_n_s_t_a_l_l
preference in the inst(1M) man page for more
information on this feature.
+o _s_w_m_g_r has a new, more compact user interface when
invoked in automatic (-a) mode.
+o swmgr and inst have integrated tardist functionality
making /_u_s_r/_s_b_i_n/_t_a_r_d_i_s_t effectively obsolete. By
publishing a link to a ._i_n_s_t selections file, you can
avoid locking up the browser while the tardist file is
downloaded from the web. Details are in the inst(1M)
man page.
+o Within _s_w_m_g_r, the product release notes can be viewed
with a single mouse click on the product of interest.
If there are no release notes for that product, nothing
will be displayed.
+o A new inst keyword, _c_o_n_f_l_i_c_t_i_n_g, refers to products
that are causing conflicts. The most common usage, _k_e_e_p
_c_o_n_f_l_i_c_t_i_n_g, attempts to deselect all products causing
conflicts. In some instances, conflicts may remain
- 19 -
after this call since not all conflicts can be resolved
by deselecting subsystems. Additionally, some required
subsystems such as eoe.sw.base may be erroneously
deselected if that product is involved in a conflict.
The user should check that all applicable required
subsystems are selected for install using the _l_i_s_t
_r_e_q_u_i_r_e_d command.
+o A new inst keyword, _p_r_e_r_e_q_s, refers to the minimal set
of unselected distribution subsystems that will resolve
the current prereq conflicts. The most common usage,
_i_n_s_t_a_l_l _p_r_e_r_e_q_s, attempts to automatically resolve all
prereq conflicts. In some instances, prereq conflicts
may remain after this call since certain subsystems
required to a resolve a conflict may not be loaded.
+o Inst and swmgr record in the installation history the
name of the distribution or CD that each product is
installed from. This information can be displayed with
the _s_h_o_w_p_r_o_d_s -_F command.
+o Miscellaneous improvements to error messages, online
help, and text output, have been made.
3.4 _C_h_a_n_g_e_s__t_o__E_m_b_e_d_d_e_d__S_u_p_p_o_r_t__P_a_r_t_n_e_r__(__E_S_P__)
+o The Embedded Support Partner (ESP), introduced with
IRIX 6.5.5, provides system administrators with a means
of monitoring various events that can occur on their
system. ESP, which is an integral part of the IRIX
operating system, introduces new daemons and a number
of commands that perform the various monitoring
activities. The new daemons include an event monitoring
daemon (_e_v_e_n_t_m_o_n_d), database daemon (_e_s_p_d_b_d), and event
management daemon (_e_s_p_e_m_d). Starting at IRIX 6.5.6,
_e_s_p_e_m_d functionality has been merged into _e_v_e_n_t_m_o_n_d.
+o Starting at IRIX 6.5.9, fixes and features introduced
in ESP2.0 patchSG0003895 ( applicable to IRIX 6.5.7m+f
and IRIX 6.5.8 m+f ) are available in this overlay. In
particular, a _c_h_k_c_o_n_f_i_g _e_s_p flag has been introduced.
Please also look at new features ( below ) and bug
fixes documented in chapter 4.
+o The types of events the Embedded Support Partner is
able to monitor include changes in system hardware
configuration (Challenge, Onyx, O2, Origin200, Octane,
Origin2000 and Onyx2 systems only), changes in software
configuration, system availability, system performance,
etc. Starting at IRIX 6.5.9, Indy hardware (_I_P_2_2)
configuration is now supported in ESP. Based on the
- 20 -
nature and severity of a particular event, specific
actions (e.g., sending a notification to the system
administrator) can be programmed to take place
automatically. ESP comes pre-installed with default
actions already in place, but can be tuned to address
specific customer support needs. In conjunction with
ESP, many of the system error messages have been
classified and tagged to allow for a more efficient
event identification and tracking. Note that the
facilities provided by the Embedded Support Partner
replace those formerly provided by the Availmon
utility.
+o The Embedded Support Partner provides system monitoring
capabilities on all systems running IRIX 6.5.5.
Optionally ESP can be configured to receive event and
system configuration data from all systems in a system
group. When operating as a Group Manager, ESP is able
to provide a single point from which to monitor all
systems in the group. ESP is controlled via a Web
browser which is connected to the Configurable Web
Server included as part of the ESP package. The browser
interface provides a means for configuring the ESP
behavior (e.g. which actions to perform for which
events) and for generating ESP reports. In the absence
of graphics, the interface uses Lynx up to IRIX 6.5.8.
Since IRIX 6.5.9, Lynx interface is _n_o_t _s_u_p_p_o_r_t_e_d and ,
instead, a command-line interface is provided via
_e_s_p_c_o_n_f_i_g(_1) _a_n_d _e_s_p_r_e_p_o_r_t(1) commands. Detailed
reports can be generated that provide insight into
system event activity, system configuration and
changes, system availability, etc. Special user-level
event types can also be defined to allow the use of ESP
facilities to monitor customer application events. For
more information, see the _e_s_p manpage.
3.4.1 _E_S_P__2_._0__N_e_w__f_e_a_t_u_r_e_s
3.4.1.1 _G_e_n_e_r_a_l
+o A _c_h_k_c_o_n_f_i_g _e_s_p flag has been introduced.
3.4.1.2 _W_e_b__I_n_t_e_r_f_a_c_e
+o The Web Interface has been totally re-designed to ease
ESP users.
+o For Web users, a printable view icon is provided
against all the reports. Clicking the icon will
generate a plain text output to the browser.
- 21 -
+o Lynx ASCII Web console has been dropped and, instead,
has been replaced with a very complete and flexible
command-line interface, _e_s_p_c_o_n_f_i_g and _e_s_p_r_e_p_o_r_t.
+o Previous version of ESP did not provide subsystem
detailed information. Now, all subsystems information
is maintained in ESP database for effectively tracking
software changes and installation.
+o Web Access now support the concept of several users.
Each user now have their respective permissions such as
configuration, report viewing, etc ...
3.4.1.3 _E_l_e_c_t_r_o_n_i_c__L_o_g_b_o_o_k
+o The Embedded Support Partner also provides the facility
of an electronic log book for logging various
activities performed on the system. The capability of a
logbook has been provided through the graphical user
interface. Entries upto 4K can be made using the
logbook capability. A set of reports are available to
view the logbook entries between any given dates. The
logbook entries are also cross referenced by the event
reports on a date basis. This allows to check if any
log entries are made against events.
3.4.1.4 _E_S_P__C_a_l_l__L_o_g_g_i_n_g__t_o__S_G_I
+o The Embedded Support Partner may also send ESP events
to a centralized database at SGI. An application
(_e_s_p_c_a_l_l) has been introduced that gets automatically
triggered against events if ESP has been configured to
send data back to SGI. The application supports both
text and compressed,encrypted, encoded formats. The
format is also selectable both in the UI and command
line applications. Information transmitted back to SGI
depends on the type of event. Information includes
customer contact information, event information,
hardware and software installed, crash analysis and
syslog information. The analysis report and syslog
messages are sent only if the system panic'd.
Information is mailed out to esp@sgi.com. Optional mail
addresses can be entered to receive copies of what is
mailed to esp@sgi.com .
3.4.2 _E_S_P__2_._0__M_i_g_r_a_t_i_o_n__i_s_s_u_e_s
+o Information maintained in ESP database is migrated in a
transparent manner. However, please note that in the
case of an SGM environment, all systems in the group
must run the same version of ESP (ESP2.0). Install
- 22 -
ESP2.0 on the System Group Manager first. Then, on the
member systems, must be installed with ESP2.0ed with
ESP2.0
+o Database from a 6.5.9 system cannot be read by an
earlier version of ESP.
+o If an SGM environment exists for ESP1.0, all systems in
the SGM environment must be upgraded to ESP2.0 for
successful operation. The Group Manager must be
upgraded first and then all members should be upgraded.
After upgrading run espconfig -sgmconvert -c on each
system starting from the group manager. The same
license of ESP1.0 if installed will work. Alternately,
set up the SGM environment again.
+o This patch introduces a 'chkconfig esp' flag. The
default is on. When you change this flag, please
consult esp(5) man page CAVEATS section for specific
instructions.
+o When the ESP User is 'administrator' and the default
password provided in ESP1.0 is used, ESP Web Access is
disabled. See details documented about BUG 774645 in
chapter 4.
+o Support for Lynx ASCII has been dropped in ESP 2.0. We
now support a command-line interface. Please consult
espconfig(1) and esperport(1) man pages for details.
+o Support for espconfig(1) qpage configuration is not
present in this release. Qpage configuration can only
be performed via the Web interface. See also
QuickPage(1M) man pages for more details.
3.5 _C_h_a_n_g_e_s _t_o _I_n_t_e_r_r_u_p_t _R_e_d_i_r_e_c_t_i_n_g _a_f_f_e_c_t_i_n_g _R_e_a_l _T_i_m_e _o_n
_T_h_e _S_G_I _3_0_0_0 _s_e_r_i_e_s
+o Hardware differences between Origin2000, and The SGI
3000 series, affect the way that interrupts can be
redirected through use of the DEVICE_ADMIN and NOINTR
directives. On Origin2000, the DEVICE_ADMIN directive
can be used to redirect interrupts to a particular
hardware CPU. On The SGI 3000 series, because of
hardware limitations, interrupts cannot be
deterministically redirected to a particular CPU.
+o The Irix 6.5.9 release includes changes to compensate
for the hardware differences between Origin2000, and
The SGI 3000 series. The current behavior on Origin2000
is not affected by these changes.
- 23 -
+o On The SGI 3000 series, if a DEVICE_ADMIN directive is
used to redirect an interrupt, the hardware limitations
may or may not allow the the interrupt to be redirected
to the requested CPU. Should this occur, the following
message will be seen on the console, and in the system
log with the hwgraph path and CPU number being as
appropriate for each case):
+o
WARNING: Override explicit interrupt targetting:
/hw/module/001c10/Ibrick/xtalk/15/pci/4/ei(0x2f8),
unable to target CPU 4
+o For a threaded interrupt handler, the
directive will still ensure that the
interrupt handler thread is given control on
the CPU specified. This will effectively
provide the same behavior that currently
exists on Origin2000.
+o If the interrupt handler is non-threaded, and
interrupt redirection is requested to ensure
the handler runs on a particular CPU, then
choice of the interrupt CPU is critical. A
device on a particular PCI bus can only
interrupt CPUs on one Processor Interface
(PI), either PI-0 or PI-1. (A device can
still interrupt CPUs on any node, but only
those on one PI.) Knowing which CPUs are
interruptable from which PCI bus is less than
clear cut, as it is determined at boot time.
Once determined, the set of interruptable
CPUs for a particular PCI bus should not
change from boot to boot, unless a system
configuration change (CPU disabled, I/O
reconfig) is made.
+o If the above mentioned warning message is
seen, indicating a interrupt redirect failed,
then the following can be done to determine
which CPUs an interrupt can be directed to,
and the DEVICE_ADMIN directive changed
accordingly. From the message, you know that
CPU 4 is on a PI that cannot receive
interrupts from the device in question.
Output from an "ls" command will show which
PI this is. In this case, it is PI-0.
+o
o3000% ls -l /hw/cpumun/4
v lrw------- ... 4 ->
- 24 -
/hw/module/001c13/node/cpubus/0/a
o3000% ls -l /hw/cpunum total lrw-
------ ... 0 ->
/hw/module/001c10/node/cpubus/0/a
lrw------- ... 1 ->
/hw/module/001c10/node/cpubus/0/b
lrw------- ... 2 ->
/hw/module/001c10/node/cpubus/1/a
lrw------- ... 3 ->
/hw/module/001c10/node/cpubus/1/b
lrw------- ... 4 ->
/hw/module/001c13/node/cpubus/0/a
lrw------- ... 5 ->
/hw/module/001c13/node/cpubus/0/b
lrw------- ... 6 ->
/hw/module/001c13/node/cpubus/1/a
lrw------- ... 7 ->
/hw/module/001c13/node/cpubus/1/b
+o You now know that the PCI bus
this device is on can only
interrupt CPUs on PI-1. Using
this knowledge and output from
"ls -l /hw/cpunum" you can
choose an interruptable CPU.
In this example, changing the
DEVICE_ADMIN directive to use
CPU 2, 3, 6, or 7, will allow
you to workaround this
hardware limitation because as
shown above, CPUs 2, 3, 6, and
7 are on PI-1.
+o Starting at release 6.5.14, on the SGI 3000 series,
customers with systems that have Xbricks may want to
rearrange the placement of XIO cards. This only
affects Xbricks that have multiple XIO cards and are
connected to two Cbricks ("dual-hosted"). Previous to
6.5.14, ownership of XIO cards within that
configuration was distributed across the two Cbricks in
an even/odd fashion (slot 8 -> Cbrick1, slot 9 ->
Cbrick2, etc). Release 6.5.14 will support some XIO
cards that occupy two XIO ports. For those cards the
even/odd distribution scheme causes both to be owned by
the same Cbrick which resulted in less than optimal
performance, so with release 6.5.14, XIO cards on
dual-hosted Xbricks will be distributed such that the
top two slots are owned by one Cbrick and the bottom
two slots are owned by the other Cbrick (slots 8 & 9 ->
Cbrick1 and slots 12 & 13 -> Cbrick2).